Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add characteristic discovery to BleService #2203

Merged
merged 7 commits into from
Nov 20, 2020

Conversation

mgolu
Copy link
Contributor

@mgolu mgolu commented Sep 23, 2020

This PR is targeting to the feature/ble_cpp_callback/ch65803 branch

Problem

Allows for hierarchical discovery of characteristics inside services.

Solution

Adds a discoverAllCharacteristics function to BleServiceImpl class.

Steps to Test

peer->discoverAllServices();
peer.getServiceByUUID(service, );
service.discoverAllCharacteristics();


Completeness

  • User is totes amazing for contributing!
  • Contributor has signed CLA (Info here)
  • Problem and Solution clearly stated
  • Run unit/integration/application tests on device
  • Added documentation
  • Added to CHANGELOG.md after merging (add links to docs and issues)

Copy link
Member

@XuGuohui XuGuohui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @mgolu for submitting this great PR! There is still something we can improve as I commented. If you'd like, I'm glad to take over this PR to make the final change.

@mgolu
Copy link
Contributor Author

mgolu commented Sep 23, 2020

Thank you @mgolu for submitting this great PR! There is still something we can improve as I commented. If you'd like, I'm glad to take over this PR to make the final change.

Yes, great comments. I agree we can refactor, I just didn't want to touch existing APIs yet. If you have the time to work on it, go for it!

@XuGuohui XuGuohui self-assigned this Sep 23, 2020
@XuGuohui XuGuohui added this to the 3.0.0 milestone Sep 23, 2020
@XuGuohui XuGuohui force-pushed the ch63765/add_ble_char_discovery_to_service branch from 502e15d to 581f75a Compare September 28, 2020 13:45
@XuGuohui XuGuohui added the ble Bluetooth Low Energy label Sep 28, 2020
Copy link
Contributor Author

@mgolu mgolu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great to save RAM by keeping just one copy of characteristics. I think the application will have to keep track of the peer associated with each service (for example, when connecting to multiple peers).

Maybe we can add a call to the BleService class that calls the peer's discoverCharacteristicsOfService? That way the application doesn't have to keep track of which peer is for each service.

wiring/src/spark_wiring_ble.cpp Outdated Show resolved Hide resolved
wiring/src/spark_wiring_ble.cpp Outdated Show resolved Hide resolved
@XuGuohui
Copy link
Member

Maybe we can add a call to the BleService class that calls the peer's discoverCharacteristicsOfService?

The initial objective of the BLE wiring APIs are designed to be easy to use for non professional developers. Thus, we just provide two main mechanisms for BLE operation, data transaction oriented and non-data transaction oriented. For non-data transaction oriented operation, we have the BLE object for local device operation and the BlePeerDevice for peer device operation. And for data transaction oriented class, we have the BleCharacteristic class. The BleService class doesn't need to touch anything about data/non-data transaction operation. I'd prefer not to introduce more APIs under the service class to make things complicate. Could you elaborate how it affects if the central is connected with multiple peers while the BleService doesn't associated with a certain peer?

@mgolu
Copy link
Contributor Author

mgolu commented Sep 30, 2020

The initial objective of the BLE wiring APIs are designed to be easy to use for non professional developers. Thus, we just provide two main mechanisms for BLE operation, data transaction oriented and non-data transaction oriented. For non-data transaction oriented operation, we have the BLE object for local device operation and the BlePeerDevice for peer device operation. And for data transaction oriented class, we have the BleCharacteristic class. The BleService class doesn't need to touch anything about data/non-data transaction operation. I'd prefer not to introduce more APIs under the service class to make things complicate. Could you elaborate how it affects if the central is connected with multiple peers while the BleService doesn't associated with a certain peer?

The use case would be for an Enterprise customer who might have multiple peers connected, which might be the same Profile or type. Then, they would have multiple BleService instances with the same UUID, but related to different peers. If they want to discover characteristics on an instance of BleService, that's currently impossible since there's no API on BleService to discover characteristics, and there's no reference to the BlePeerDevice that the instance is associated with. That means that the developer needs to keep track themselves of each BleService instance association to a BlePeer.

@XuGuohui
Copy link
Member

I see no reason to keep tracking a BLE service with a peer device in user application. For discovering characteristics under a peer associated service, we can call peer.discoverCharacteristicsOfService() that is introduced in this PR. Other than that, we don't need to operate a BLE service. Whenever we want to retrieve a peer associated service, you can call peer.services() or peer.getServiceByUUID(). So we just need to track the peer devices it connected. As for data transmission, we use characteristic methods, which is already peer associated.

@mgolu
Copy link
Contributor Author

mgolu commented Oct 8, 2020

I tested with the new proposed BLE Gateway library (https://github.com/particle-iot/ble-gateway-library) and the new changes are working well. Just submitted a small fix.

@XuGuohui
Copy link
Member

@avtolstoy Do you have any comment here?

@XuGuohui XuGuohui force-pushed the ch63765/add_ble_char_discovery_to_service branch from 7a255ce to 7f1806e Compare October 26, 2020 13:53
@XuGuohui XuGuohui changed the base branch from develop to feature/ble_scan_filter/ch37224 October 26, 2020 13:54
@XuGuohui XuGuohui changed the base branch from feature/ble_scan_filter/ch37224 to feature/ble_cpp_callback/ch65803 October 26, 2020 13:55
@mgolu
Copy link
Contributor Author

mgolu commented Nov 10, 2020

Can this branch be merged into develop?

@XuGuohui
Copy link
Member

Can this branch be merged into develop?

We will get it merged in this sprint (in two weeks). Cc. @avtolstoy

@@ -1001,10 +1002,24 @@ class BleServiceImpl {
return endHandle_;
}

bool& characteristicsDiscovered() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1847 (comment) :)

Nit: This is a really weird pattern when considering trivial types. I'd rather have this as a public member then or use setters/getters.

@XuGuohui XuGuohui force-pushed the feature/ble_cpp_callback/ch65803 branch from d567d5b to e3967bb Compare November 20, 2020 13:28
Base automatically changed from feature/ble_cpp_callback/ch65803 to develop November 20, 2020 14:12
@XuGuohui XuGuohui force-pushed the ch63765/add_ble_char_discovery_to_service branch from 0abf96c to 84ebbd9 Compare November 20, 2020 15:41
@XuGuohui XuGuohui force-pushed the ch63765/add_ble_char_discovery_to_service branch from 84ebbd9 to 28175ba Compare November 20, 2020 16:08
@XuGuohui XuGuohui merged commit 9d89600 into develop Nov 20, 2020
@XuGuohui XuGuohui deleted the ch63765/add_ble_char_discovery_to_service branch November 20, 2020 16:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants